In the past, computer programs could be considered a stack of instructions executed sequentially on a single machine. The developer, typically using a debugger running on the same machine, could set a breakpoint at some point in the stack. When the breakpoint is encountered, the program stops running. The developer could then glean whatever information might be of interest.
Nowadays, computer programs often run in a “distributed” environment, where programs run across a plurality (tens, sometimes hundreds) of networked machines. Processes distributed among the several machines communicate with each other over the network via simple object access protocol (“SOAP”) messages. Consequently, a developer might not be on the machine running the portion of the program he wants to break.
In a distributed environment, a developer could “attach” to the machine-of-interest and evaluate the program remotely. Sometimes, however, the developer does not know which of the plurality of machines is running the portion of the program he wants to break. The developer might not even know that the machine he wants to break exists. For example, the developer, at a first machine, might send a message to a second machine. Unknown to the developer, however, the second machine sends a message to a third machine in order to perform the function required by the message sent from the developer's machine. The second machine gets its answer from the third machine and sends the first machine its answer. The developer at the first machine may have no idea that the third machine was even involved in the processing. The third machine, however, might be the machine that the developer needs to break to determine what is wrong with the program. Thus, there is a need in the art for a distributed debugging system that works in this environment.